home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload Trio 2 / Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO / dir24 / mb1705.zip / BBS_SPEC.DOC < prev    next >
Text File  |  1994-05-13  |  25KB  |  862 lines
  1.  
  2. Changes:
  3.  
  4. CTL-C not really restricted character?
  5. LF not used as alternate EOL
  6. Added info from AA4RE on "M in SID".
  7. Added info from W0RLI on "X in SID".
  8.  
  9. Legal character set for BID?
  10.  
  11. ...  Hank
  12.  
  13.  
  14.   BBS Interface Specification
  15.   Working Draft
  16.   11/28/93
  17.  
  18.  
  19.   Introduction
  20.   Section 1 - Establishing connection
  21.   Section 2 - Forwarding
  22.   Section 3 - Reverse forwarding
  23.   Section 4 - Forwarding to old BBSs
  24.   Section 5 - Error Conditions
  25.   Section 6 - BNF Summary
  26.   Section 7 - Feature Letter Use
  27.  
  28.  
  29.   Current mailing list
  30.   BBS_authors@arasmith.com
  31.  
  32.               bob@arasmith.com (Bob Arasmith, N0ARY)
  33.               hank_oredson@mentorg.com (Hank Oredson, W0RLI)
  34.               wd6cmu@netcom.com (Eric Williams, WD6CMU)
  35.               enge@almaden.ibm.com (Roy Engehausen, AA4RE)
  36.               71151.720@CompuServe.COM (Victor Poor, W5SMM)
  37.               blloyd@axion.bt.co.uk (Brian Lloyd, G1NNA)
  38.               map@hopper.cba.csuohio.edu (Mike Pechura, WA8BXN)
  39.               durham@w2xo.pgh.pa.us (James Durham, W2XO)
  40.               johan@ece.orst.edu (Johannes Reinalda, WG7J)
  41.               trentin@enac.dgac.fr (to J-P Roubelat, F6FBB)
  42.               sproul@sproul.com (Mark Sproul, KB2ICI)
  43.               mike@km6px.arasmith.com (Mike Stickney, KM6PX)
  44.               70007.1365@compuserve.com (Ed Juge, W5TOO)
  45.               73126.3260@compuserve.com (Craig McCartney, WA8DRZ)
  46.               bbr77@aol.com (Brian Riley, KA2BQE)
  47.  
  48.   Via US Mail
  49.             Michael Jaggers, WB4TTZ
  50.                 1377 Columbia Ave, Franklin, TN  37064
  51.  
  52.   Introduction -
  53.   This document is meant to define the interaction between two BBSs
  54.   exchanging messages. It is not the goal of the document to specify
  55.   the interface of the future but merely represent what a BBS can be
  56.   expected to see at the current time.
  57.  
  58.   It is hoped that this specification will be followed by another that
  59.   defines the base rules for all BBS programs to adopt. This should
  60.   eliminate the current problems with incompatibilities and overloaded
  61.   operators. If you create a BBS to this specification you should be
  62.   able to interconnect with virtually any BBS currently in use. Any
  63.   extensions you add will put you at risk, the subsequent spec is to
  64.   identify these areas.
  65.  
  66.   In brief the following sequence of events takes place when the BBSs
  67.   connect for forwarding:
  68.  
  69.  
  70.   Master System             Slave System
  71.   ------------                --------------
  72.   {Connect}
  73.                     [SID]
  74.                     N9ZZZ >
  75.  
  76.   [SID]
  77.  
  78.                     >
  79.  
  80.   SB ARES @ ALLCA < W7ZZZ $ARES0108
  81.  
  82.                     OK
  83.  
  84.   message subject
  85.   message routing headers
  86.   message body
  87.   /EX
  88.  
  89.                     >
  90.  
  91.   SB WANT @ ALLUS < W8AAA $1029_N0XYZ
  92.  
  93.                     NO
  94.                     >
  95.  
  96.   F>
  97.  
  98.                     SP WA2ABC @ N2AAA < N9AAA
  99.  
  100.   OK
  101.  
  102.                     message subject
  103.                     message routing headers
  104.                     message body
  105.                     /EX
  106.  
  107.   F>
  108.  
  109.                     {Disconnect}
  110.  
  111.   This represents a simple example of connecting, establishing a common
  112.   protocol, forwarding and reverse forwarding. This document will look
  113.   more closely at each of these phases.
  114.  
  115.   In the text the BBS initiating the connect will be referred to as the
  116.   MASTER and the remote BBS will be referred to as the SLAVE.
  117.  
  118.   Each command and exchange will be presented in BNF (Backus-Naur Form)
  119.   which is a context-free grammar widely used to describe computer
  120.   language syntax.
  121.  
  122.   All commands and fields are case insensitive.
  123.  
  124.   Meta-syntactic information
  125.  
  126.     [x]   =    Optional: zero or one x
  127.     (x y) =    Grouping: treat multiple tokens as a single token
  128.     <>      =    Set
  129.  
  130.   Characters:
  131.  
  132.     NUL =    <0x00>
  133.     CNTRL_C =    <0x03>
  134.     TAB =    <0x09>
  135.     CR =    <0x0D>
  136.     LF =    <0x0A>
  137.     CNTRL_Z =    <0x1A>
  138.     SP =    <0x20>
  139.  
  140.   Character sets:
  141.  
  142.     ALPHA =    <'A'-'Z'>
  143.     DIGIT =    <'0'-'9'>
  144.     ALNUM =    ALPHA | DIGIT
  145.     ASCII =    <0x20-0x7F>
  146.     SPACE =    SP | TAB
  147.     8BIT  =    <0x01 - 0xff, except CR, LF, CTRL_Z>
  148.  
  149.   Character sequences:
  150.  
  151.     EOL =    CR | CR LF
  152.  
  153.     NUMBER =    DIGIT | NUMBER DIGIT
  154.     WHITE =    SPACE | WHITE SPACE
  155.  
  156.     ASCII_STR = ASCII | ASCII_STR ASCII
  157.     ALNUM_STR = ALNUM | ALNUM_STR ALNUM
  158.     8BIT_STR  = 8BIT  | 8BIT_STR  8BIT
  159.  
  160.   Throughout this document we will present a verbose translation of the
  161.   grammar highlighting any points that may not be obvious but could
  162.   have significant affect. There will also be examples illustrating what
  163.   can actually be expected.
  164.  
  165.   Section 1 - Establishing connection
  166.  
  167.   When connecting to a BBS the first line the BBS sends must be the
  168.   SID (System IDentifier). The SID is used to determine what features
  169.   are supported by BBS. The existence of the SID implies that the system
  170.   supports reverse forwarding and OK/NO message rejection. There still
  171.   exist old BBS codes which do not present a SID at connect. Refer to
  172.   Section 4 for information on forwarding to these old style BBS sytems.
  173.  
  174.   SID sent by both MASTER and SLAVE
  175.  
  176.     AUTHOR_ID     =  <ASCII_STR, except '[', ']' and '-'>
  177.     AUTHOR_DATA  =  <ASCII_STR, except '[' and ']'>
  178.     FEATURE     =  ALPHA [DIGIT]
  179.     FEATURE_LIST =  FEATURE | FEATURE_LIST FEATURE
  180.     SID      =  "[" AUTHOR_ID "-" [AUTHOR_DATA "-"] FEATURE_LIST [$]"]" EOL
  181.  
  182.  
  183.     The AUTHOR_ID and FEATURE_SET must be present. If the optional
  184.     AUTHOR_DATA is present it must be separated from the other two
  185.     fields by a '-'. AUTHOR_DATA may contain the '-' character.
  186.  
  187.     The AUTHOR_ID and AUTHOR_DATA are typically a portion of the authors
  188.     callsign or BBS name and version number, respectively.
  189.  
  190.     Each FEATURE consists of a letter, denoting the feature and an
  191.     optional number, denoting the feature level. The absence of a
  192.     version number implies version zero.
  193.  
  194.     If BID's are supported, '$' must be the last symbol in the FEATURE_SET.
  195.  
  196.     The recommended minimal support is BID and Hierarchical location
  197.     identifiers. These are necessary for the proper operation of the network.
  198.  
  199.     EXAMPLE
  200.  
  201.       [ZFJ-2.3-H$]
  202.  
  203.   The original prompt received from the SLAVE BBS may contain additional
  204.   information intended for users. As soon as the SID is received by the
  205.   SLAVE BBS it should respond with an abbreviated PROMPT, with the
  206.   ASCII_STR field being empty.
  207.  
  208.   Section 2 - Forwarding
  209.  
  210.   A message can either be rejected or accepted by the SLAVE. There are
  211.   many reasons that the SLAVE my choose to reject a message but the most
  212.   common will be duplicate bid, indicating the SLAVE already has the message.
  213.   Here is an overview of the exchange.
  214.  
  215.  
  216.   ACCEPT EXCHANGE:
  217.  
  218.     MASTER        SLAVE
  219.     ------        -----
  220.             PROMPT
  221.     SEND_CMD
  222.             RESPONSE (OK)
  223.     MESSAGE
  224.             COMMENT
  225.             PROMPT
  226.  
  227.   REJECT EXCHANGE:
  228.  
  229.     MASTER        SLAVE
  230.     ------        -----
  231.             PROMPT
  232.     SEND_CMD
  233.             RESPONSE (NO)
  234.             PROMPT
  235.  
  236.   The SLAVE indicates it's prepared to accept a command by issuing a PROMPT.
  237.   The PROMPT is also used as an an acknowledgement that the last message
  238.   has be received.
  239.  
  240.   The MASTER initiates the message exchange by issuing a a SEND_CMD. This
  241.   command contains all the information necessary for the SLAVE to decide
  242.   whether to ACCE or REJECT the message. It contains message type,
  243.   destination, originator and possibly a bid.
  244.  
  245.     COMMENT =    <ASCII_STR, except '>'>
  246.     PROMPT  =    [COMMENT] ">" EOL
  247.  
  248.     TYPE =    'B' | 'P' | 'T'
  249.     CALLSIGN =    <ASCII_STR, except '@', '.', max length 6>
  250.     LOC =    <ASCII_STR, except '@', '.', max length 6>
  251.     HLOC =    LOC | <HLOC "." LOC, max length 31>
  252.     BBS =    CALLSIGN ["." HLOC]
  253.     TO =    CALLSIGN [WHITE "@" WHITE BBS]
  254.     FROM =    CALLSIGN
  255.     BID =    <ASCII_STR, max length 12>
  256.  
  257.     SEND_CMD =    "S" TYPE WHITE TO [WHITE "<" WHITE FROM] [WHITE "$" BID]
  258.  
  259.  
  260.     HLOC is the hierarchical location of the system. It is defined by
  261.     the document "INTERNATIONAL ROUTING DESIGNATORS", ARRL Networking
  262.     Conference Proceedings xxx.
  263.  
  264.     The TO field commonly takes the following forms:
  265.  
  266.       callsign @ BBS.hloc        ; N6ZFJ @ N6QMY.CA.USA.NA
  267.       category @ distrib        ; WANT @ ALLCA
  268.       category @ BBS.hloc        ; WANT @ N6QMY.CA.USA.NA
  269.       category @ distib.hloc    ; INFO @ ALLCA.CA.USA.NA
  270.  
  271.     The first two are seen most often, but the other two forms are seen.
  272.     The first two forms are also normally associated with the
  273.     message type of PERSONAL and BULLETIN respectively.
  274.  
  275.     White space is required on either side of the '@' and between the
  276.     '<' and the senders callsign. There cannot be white space between
  277.     the '$' and the BID.
  278.  
  279.  
  280.     EXAMPLE
  281.  
  282.       SB WANT @ ALLSCV < N6ZFJ $2345_N6QMY
  283.  
  284.     A "BID" (Bulletin IDentifier) is associated with each Bulletin,
  285.     and may be associated with any Personal message.
  286.  
  287.     If a BID is not given explicitly when the message is entered into
  288.     the system, and the message type requires a BID, one is created
  289.     automatically from the message number and callsign of the system
  290.     into which the message was initially entered.
  291.  
  292.     NOTE:
  293.  
  294.     It is suggested that a generated BID have the form nnn_BBS,
  295.     where nnn is the message number at the originating BBS system,
  296.     and BBS is the callsign of the originating BBS system.
  297.  
  298.     COMMON_BID =    MSG_NUM "_" CALLSIGN
  299.  
  300.     BBS codes are free to create whatever form they wish as long as the
  301.     length doesn't exceed 12 characters.
  302.  
  303.     Messages to a distribution, whether they are bulletins or personal
  304.     messages, must have a BID. Personal messages to a specific user may
  305.     carry a BID if the user supplied one, but will not be given a default
  306.     BID. NTS message never carry a BID.
  307.  
  308.   The SLAVE BBS determines from the SEND_CMD whether or not to accept
  309.   the message. The reasons for rejection is usually that the message
  310.   already exists on the SLAVE system (i.e. a duplicate BID), or possibly
  311.   a system related problem.
  312.  
  313.   Sent by SLAVE in response to SEND_CMD (or by MASTER if in reverse
  314.   forward mode).
  315.  
  316.     RESPONSE =    ACCEPT | REJECT
  317.  
  318.     ACCEPT =    "OK" [ WHITE COMMENT ] EOL
  319.  
  320.     REJECT =    "N" [ "O" ] [ WHITE COMMENT ] EOL
  321.  
  322.     NOTE:
  323.     The syntax of responses has grown in a random fashion. Many BBS programs
  324.     expect to see the entire words "OK" and "NO" while others simply look
  325.     at the first letter. It is suggested that new BBS codes should present the
  326.     words "NO" and "OK", but look for only the first letter. Doing so should
  327.     ensure compatibility with existing BBS codes.
  328.  
  329.     EXAMPLE
  330.       Master:  SB WANT @ ALLCAN < N6ZFJ $4567_N0ARY
  331.       Slave:   NO duplicate bid
  332.       Slave:   >
  333.  
  334.       Master:  SB WANT @ ALLCAN < N6ZFJ $4567_N0ARY
  335.       Slave:   OK #32190
  336.       Master:  message body
  337.       Master:  /EX
  338.       Slave:   Message being held for sysop review
  339.       Slave:   >
  340.  
  341.     It is required that the "OK" and "NO" strings be followed by white
  342.     space or EOL. Some BBS programs will fail to recognize them otherwise.
  343.  
  344.     EXAMPLE
  345.       Master:  SB WANT @ ALLCAN < N6ZFJ $4567_N0ARY
  346.       Slave:   NO, already have it
  347.       Slave:   >
  348.  
  349.       This would fail with some existing BBS codes due to
  350.       the comma following the "NO" string.
  351.  
  352.  
  353.   If the SLAVE BBS responds with a REJECT condition the message should
  354.   not be sent and the MASTER should ignore any response from the SLAVE
  355.   until PROMPT is encountered. The MASTER can then submit a new SEND_CMD,
  356.   initiate reverse forwarding or disconnect.
  357.  
  358.   Once the SLAVE has issued the ACCEPT response, the MASTER BBS
  359.   should immediately send the message subject, routing headers,
  360.   message body and EOM. The SLAVE will acknowledge with PROMPT
  361.   once it receives an EOM.
  362.  
  363.     Message Routing Header
  364.  
  365.     SUBJECT =  <ASCII_STR, max length 79> EOL
  366.     YEAR    =  DIGIT DIGIT
  367.     MONTH   =  DIGIT DIGIT
  368.     DAY     =  DIGIT DIGIT
  369.     HOUR    =  DIGIT DIGIT
  370.     MINUTE  =  DIGIT DIGIT
  371.  
  372.     STAMP   =    "R:" YEAR MONTH DAY "/" HOUR MINUTE ["Z"]
  373.     MSG_NUM =    <NUMBER, range 1 - 65535 (0xFFFF)>
  374.  
  375.     HEADER1 =    STAMP WHITE MSG_NUM "@" BBS EOL
  376.     HEADER2 =    STAMP WHITE "@:" BBS WHITE [ASCII_STR] "#:" MSG_NUM [ASCII_STR]
  377.     HEADER  =    HEADER1 | HEADER2
  378.  
  379.     Message structure
  380.  
  381.     HEADERS =    HEADER | HEADERS HEADER
  382.     EOM     =    (CNTRL_Z EOL) | (EOL "/EX" EOL)
  383.     BODY    =    8BIT_STR | BODY EOL 8BIT_STR
  384.     MESSAGE =    SUBJECT [HEADERS] EOL [BODY] EOM
  385.  
  386.     EXAMPLE
  387.  
  388.       Example message
  389.       R:930108/1729 @:N6QMY.#NOCAL.CA.USA.NA Fremont #:1114 Z:94536
  390.       R:930108/1259 1530@KA6FUB.#NOCAL.CA.USA.NA
  391.       R:930107/1638z @:WD6CMU.#NOCAL.CA.USA.NA "OSKbox" #:10576 Z:94805
  392.       R:930107/1045 50724@WX3K.#NOCAL.CA.USA.NA
  393.  
  394.       message body will go here, the blank line above separates the
  395.       body from the routing headers. When the body is through it should be
  396.       terminated as follows:
  397.       /EX
  398.  
  399.     NOTE:
  400.     Both forms of the header described above are seen, and should be parsed.
  401.     In either case there may be comments found at the end of the header line,
  402.     or between the BBS and the MSG_NUM entries in HEADER2.
  403.  
  404.     HEADER2 is derived from the header form used in early BBS codes.
  405.     it allows addtional information to be passed in the header and parsed
  406.     if desired. Some examples of these additional fields seen are:
  407.  
  408.       Z:zipcode
  409.       O:orginator
  410.       $:bid
  411.       C:name_of_sysops_cat
  412.  
  413.     NOTE:
  414.     The time stamp in the routing header must be in GMT. Some existing BBS
  415.     codes provide the time stamp in other than GMT, and may include a time
  416.     zone indicator after the time stamp. This should be considered in the
  417.     design of header parsers.
  418.  
  419.     Each system that handles the message places it's routing header
  420.     at the top of the message headers before passing the message to
  421.     the next BBS. The headers must begin in column 1. A blank line
  422.     separates the routing headers from the body of the message.
  423.  
  424.     The last (oldest) routing header shows the BBS where the message
  425.     originated. This header is the only source for this information.
  426.     The information about the originating BBS is used to create a
  427.     return address for reply messages.
  428.  
  429.     Here are two examples of the same header, in the two different formats:
  430.  
  431.       R:930101/0000 1530@KA6FUB.#NOCAL.CA.USA.NA
  432.       R:930101/0000 @:KA6FUB.#NOCAL.CA.USA.NA #:1530
  433.  
  434.     These examples show the different syntax for the message number and
  435.     originating BBS address. All fields not shown in the examples are
  436.     optional at the discretion of the sysop.
  437.  
  438.   Section 3 - Reverse forwarding
  439.  
  440.   Once all messages have either been successfully forwarded from the MASTER
  441.   to the SLAVE, or been rejected by the SLAVE, the MASTER may accept
  442.   messages from the SLAVE. i.e. the MASTER and SLAVE exchange roles.
  443.   This is called "reverse forwarding".
  444.  
  445.   ACCEPT EXCHANGE:
  446.  
  447.     MASTER        SLAVE
  448.     ------        -----
  449.             PROMPT ">"
  450.     REV_FWD "F>"
  451.             SEND_CMD
  452.     RESPONSE "OK"
  453.             MESSAGE
  454.     COMMENT
  455.     REV_FWD "F>"
  456.  
  457.   REJECT EXCHANGE:
  458.  
  459.     MASTER        SLAVE
  460.     ------        -----
  461.             PROMPT ">"
  462.     REV_FWD "F>"
  463.             SEND_CMD
  464.     RESPONSE "NO"
  465.     REV_FWD "F>"
  466.  
  467.   The MASTER indicates that it is ready to accept a message by answering
  468.   the SLAVE's PROMPT, ">",  with a REV_FWD command, "F>". At that point the
  469.   SLAVE issues a SEND_CMD and the process continues as described in
  470.   section 2 but with the rolls of MASTER and SLAVE reversed. The only
  471.   difference is that the MASTER will always respond with REV_FWD in
  472.   place of PROMPT to indicate successful transfer.
  473.  
  474.     REV_FWD =    "F>" EOL
  475.  
  476.   The reverse forwarding phase is optional and is under the control of
  477.   the MASTER. It can be terminated by any of the following:
  478.  
  479.     SLAVE disconnects
  480.  
  481.     SLAVE sends anything other than a legal SEND_CMD
  482.  
  483.     MASTER disconnects
  484.  
  485.     MASTER sends anything other than "F>".
  486.  
  487.   Section 4 - Forwarding to old BBSs
  488.  
  489.   If the SLAVE does not return a SID then it is assumed that it will
  490.   not support BIDs nor OK/NO message rejection.
  491.  
  492.   The SLAVE indicates it is prepared to accept a command by issuing a
  493.   PROMPT. This PROMPT is also an acknowledgement that the last message
  494.   has been received.
  495.  
  496.   The MASTER initiates the message exchange by issuing a SEND_CMD with no
  497.   HLOC or BID. The SLAVE has no way to reject the message so the MASTER
  498.   proceeds to send the message subject and body without expecting
  499.   acknowlegement from the SLAVE.
  500.  
  501.   Since the SLAVE assumes a user is entering the message, it will display
  502.   prompts to lead the user through the message sending process, asking for
  503.   a subject, prompting for the message body, etc. The MASTER should
  504.   consider this text to be part of the PROMPT and ignore it.
  505.  
  506.   As in Section 2, the MASTER waits until PROMPT is received. This is the
  507.   acknowledgement that the message has been recieved and the next message
  508.   can be sent.
  509.  
  510.   When the MASTER has no additional messages to send it disconnects
  511.   from the SLAVE. Reverse forwarding is not supported in this situation.
  512.  
  513.   Section 5 - Error Conditions
  514.  
  515.   When an error of any nature is detected by either the MASTER or the SLAVE,
  516.   that station will disconnect at once, without issuing a PROMPT.
  517.  
  518.  
  519.   Section 6 - BNF Summary
  520.  
  521.   Meta-syntactic information.
  522.  
  523. [x]         =    Optional Zero or one x.
  524. (x y)         =    Grouping.  Treat multiple tokens as single token.
  525. <>         =    Set.
  526.  
  527.   Characters of interest.
  528.  
  529. TAB         =    <0x09>
  530. LF         =    <0x0a>
  531. CR         =    <0x0d>
  532. CNTRL_Z      =    <0x1a>
  533. SP         =    <0x20>
  534.  
  535.   Character sets of interest.
  536.  
  537. ALPHA         =    <'A' - 'Z', 'a' - 'z'>
  538. DIGIT         =    <'0' - '9'>
  539. ALNUM         =    ALPHA | DIGIT
  540. ASCII         =    <0x20 - 0x7f>
  541. SPACE         =    SP | TAB
  542. 8BIT         =    <0x01 - 0xff, except CR, LF, CTRL_Z>
  543.  
  544.   Character sequences of interest.
  545.  
  546. EOL         =    CR | CR LF
  547.  
  548. NUMBER         =    DIGIT | NUMBER DIGIT
  549. WHITE         =    SPACE | WHITE SPACE
  550.  
  551. ASCII_STR    =    ASCII | ASCII_STR ASCII
  552. ALNUM_STR    =    ALNUM | ALNUM_STR ALNUM
  553. 8BIT_STR     =    8BIT  | 8BIT_STR  8BIT
  554.  
  555.   System identifier syntax.
  556.  
  557. AUTHOR_ID    =    <ASCII_STR, except '[', ']', '-'>
  558. AUTHOR_DATA  =    <ASCII_STR, except '[', ']'>
  559. FEATURE      =    ALPHA [DIGIT]
  560. FEATURE_LIST =    FEATURE | FEATURE_LIST FEATURE
  561. SID         =    "[" AUTHOR_ID ["-" AUTHOR_DATA] "-" FEATURE_LIST "]" EOL
  562.  
  563.   System Prompt syntax.
  564.  
  565. COMMENT      =     <ASCII_STR, except '>'>
  566. PROMPT         =     [COMMENT] ">" EOL
  567.  
  568.   Send Command syntax.
  569.  
  570. TYPE         =    'B' | 'P' | 'T'
  571. CALLSIGN     =    <ASCII_STR, except '@', '.', ' ', max length 6>
  572. LOC         =    <ASCII_STR, except '@', '.', ' ', max length 6>
  573. HLOC         =    <LOC | HLOC "." LOC, max length 31>
  574. BBS         =    CALLSIGN ["." HLOC]
  575. TO         =    CALLSIGN [("@" | WHITE "@" WHITE) BBS]
  576. FROM         =    CALLSIGN
  577. BID         =    <ASCII_STR, except ' ', max length 12>
  578. SEND         =    "S" TYPE WHITE TO [WHITE "<" WHITE FROM] [WHITE "$" [BID]]
  579.  
  580.   Message syntax.
  581.  
  582. SUBJECT   =  <ASCII_STR, max length 79> EOL
  583.  
  584. YEAR      =  DIGIT DIGIT
  585. MONTH      =  DIGIT DIGIT
  586. DAY      =  DIGIT DIGIT
  587. HOUR      =  DIGIT DIGIT
  588. MINUTE      =  DIGIT DIGIT
  589. STAMP      =  "R:" YEAR MONTH DAY "/" HOUR MINUTE
  590. MSG_NUM   =  <NUMBER, range 1 - 65535>
  591. HEADER1   =  STAMP WHITE MSG_NUM "@" BBS EOL
  592. HEADER2   =  STAMP WHITE "@:" BBS WHITE [ASCII_STR] "#:" MSG_NUM [ASCII_STR]
  593. HEADER      =  HEADER1 | HEADER2
  594. HEADERS   =  HEADER | HEADERS HEADER
  595.  
  596. BODY      =  8BIT_STR | BODY EOL 8BIT_STR
  597. EOM      =  (CTRL_Z EOL) | (EOL "/EX" EOL)
  598. MESSAGE   =  SUBJECT [HEADERS] EOL [BODY] EOM
  599.  
  600.   Standard message identification syntax.
  601.  
  602. MSG_ID         =    MSG_NUM "_" CALLSIGN
  603.  
  604.  
  605.   Section 7 - Feature Letter Use
  606.  
  607. Feature $:
  608.  
  609.   Supports BIDs.
  610.  
  611. Feature A:
  612.  
  613.   F6FBB - Acknowledge for personal messages.
  614.  
  615. Feature B:
  616.  
  617.   F6FBB - Binary messages supported.
  618.  
  619. Feature C:
  620.  
  621.   Obsolete:  Supports automatic distribution of current date / time.
  622.          (W0RLI, K0ZXF)
  623. Feature F:
  624.  
  625.   F6FBB - Batch forwarding protocol.
  626.  
  627. Feature H:
  628.  
  629.   Supports Hierarchical Location designators.
  630.  
  631. Feature I:
  632.  
  633.   Some transport mechanisms do not identify the calling station in the
  634.   protocol as AX25 does. To handle this situation, a "null command"
  635.   is defined as a line beginning with ';'. This allows the sending station
  636.   to send callsigns to satisfy the regulations for station identification.
  637.  
  638.   EXAMPLE
  639.  
  640.     ; W5SMM de W0RLI
  641.  
  642.   The receiving station must ignore such lines.
  643.  
  644. Feature L:
  645.  
  646.   G1nna - Compression.
  647.  
  648. Feature M:
  649.  
  650.   For AA4RE systems:
  651.  
  652.   Basic level ("M0")
  653.     MID = message identifier
  654.     Every message has a MID.
  655.     The MID looks like a "generated" BID (example 12345_AA4RE).
  656.     The "M" letter in the SID indicates that a MID is to be transmitted
  657.     with messages that have no BID.
  658.  
  659.     Processing:
  660.  
  661.     If a send command is received by a BBS with a MID, the program
  662.     should determine if it is a duplicate.  If it is, the program
  663.     should respond with the usual "NO" as if it was matching a BID.
  664.  
  665. Feature R:
  666.  
  667.   AA4RE - Extended reject responses.
  668.  
  669.   OK
  670.     Yes, send to me.  Note that no number is required.    This may
  671.     help eliminate phantom message numbers.
  672.  
  673.   NO
  674.     This is a real dupe
  675.   REJECT
  676.     I can't handle this
  677.   LATER
  678.     Send to me later ...
  679.  
  680.   The LATER is useful when you are already receiving a bulletin on one
  681.   connect and someone else tries to send you the same bulletin.
  682.  
  683.   REJECTed messages should be called to the attention of the SYSOP
  684.   to see why the reject occurs.
  685.  
  686.   The difference between NO and REJECT is whether or not SYSOP attention
  687.   is needed.
  688.  
  689.   Abreviations are alloed: 1 Letter only ... O N L R
  690.  
  691.   There must be a blank after the word or letter.  This one is fine:
  692.     N Already have it.
  693.   This one is not correct:
  694.     REJECT, Something wrong
  695.   The comma is not allowed.
  696.  
  697. Feature S:
  698.  
  699.   AA4RE - Extended "S" commands.
  700.  
  701. Feature X:
  702.  
  703.   W0RLI - Supports ihave/iwant compressed batch forwarding.
  704.  
  705.      A standard for Data compression during the forwarding
  706.      of messages in the Amateur Radio BBS Network.
  707.  
  708.      o ihave/iwant variable batch size protocol
  709.      o Feature letter X, commands SS, SX, SY.
  710.      o lzh compression
  711.  
  712. ----------------------------------------------------------------------------
  713.      Command Definitions and BNF description.
  714. ----------------------------------------------------------------------------
  715.  
  716.   N         = INTEGER, size 32 bits.
  717.   protocol   = TBD
  718.   batch_size = N
  719.   file_size  = N
  720.   msg_count  = <0 - 25>
  721.   cksum      = <file checksum>
  722.  
  723.   id         = BID | MID CR
  724.   ids         = id | ids id
  725.  
  726.   byte         = <0x00 - 0xff)
  727.   bytes      = byte | bytes byte
  728.  
  729.   ihave = "SX " msg_count [" " protocol] [" " batch_size] CR [ids]
  730.   iwant = "SY " msg_count CR [ids]
  731.   isend = "SS " file_size [" " cksum] CR bytes
  732.  
  733.   For ihave:
  734.   Protocol and batch_size not used in initial implementation.
  735.   Default protocol is: lzh compressed export/import file.
  736.  
  737.   For iwant:
  738.   SY means want only these.
  739.  
  740.   Note that the SS command must terminate with CR, without LF.
  741.  
  742.   The optional checksum is computed by summing all the bytes
  743.   in the file as unsigned integers.  Example code:
  744.   {
  745.     int byte;
  746.     unsigned int sum;
  747.  
  748.     sum = 0;
  749.     for (all bytes in file) sum += byte;
  750.   }
  751.  
  752.   RFC-822 header fields used are:
  753.  
  754.   To:
  755.   From:
  756.   Subject:
  757.   Message-ID:
  758.   X-msgtype:
  759.   X-BID:
  760.  
  761. ----------------------------------------------------------------------------
  762.      The basic interchange (example):
  763. ----------------------------------------------------------------------------
  764.  
  765.   bn are BIDs (or MID if message has no BID).
  766.   m: is master, s: is slave.
  767.  
  768. m: SX 5
  769. m: b1
  770. m: b2
  771. m: b3
  772. m: b4
  773. m: b5
  774.  
  775. s: SY 3
  776. s: b1
  777. s: b3
  778. s: b5
  779.  
  780. m: SS 26545
  781. m: <sends 26545 byte file>
  782.  
  783. In the case of any error, the station noticing the error must disconnect.
  784.  
  785. ----------------------------------------------------------------------------
  786.      With more detail of one implementation (MB/SERVER processing)
  787. ----------------------------------------------------------------------------
  788.  
  789.   Maximum batch size defined globally (default), and per link.
  790.   Ability to turn compression on/off (add/drop feature X in SID).
  791.  
  792.  
  793. From sending side:
  794.  
  795.    MB:
  796.  
  797.    Scan messages to find a batch just larger than max batch size.
  798.    Keep record numbers and cc: id in list.
  799.    Send ihave.
  800.    Receive iwant.
  801.    Mark all messages in ihave and not in iwant as forwarded (dup bid).
  802.    Pass iwant list to SERVER in file.
  803.    Wait for server acknowledge.
  804.  
  805.    SERVER:
  806.  
  807.    Create export file.
  808.    Compress export file.
  809.    Signal MB that compressed file ready to send.
  810.  
  811.    MB:
  812.  
  813.    Send isend, send the file.
  814.    Receive prompt.
  815.    Mark all messages in iwant as forwarded.
  816.  
  817. From receiving side:
  818.  
  819.    MB:
  820.  
  821.    Receive ihave.
  822.    Check bids in ihave.
  823.    For all non-dup bids, make iwant list.
  824.    Send iwant.
  825.    Receive compressed file.
  826.    Signal SERVER import file available.
  827.    Send prompt.
  828.  
  829.    SERVER:
  830.  
  831.    Decompress file, import messages.
  832.  
  833.  
  834.  
  835.   Section 8 - Import / Export files.
  836.  
  837. Import/Export files may contain any number of messages.
  838. Each message is terminated by "/EX" EOL
  839.  
  840.   RFC-822 header use in import/export files.
  841.  
  842. The standard RFC-822 keywords which must be supported are:
  843.  
  844.   To:
  845.   From:
  846.   Subject:
  847.   Message-ID:
  848.   cc:
  849.  
  850. Extension keywords which must be supported are:
  851.  
  852.   X-msgtype:       (W0RLI)
  853.   X-BBS-Msg-Type:  (JNOS)
  854.  
  855.   X-BID:       (W0RLI)
  856.  
  857.   X-BBS-Hold:       (JNOS)
  858.   X-Forwarded-To:  (JNOS)
  859.  
  860. END OF SPEC
  861.  
  862.